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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document defines the general aspects of the specification of supplementary services at the layer 3 radio 
interface within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document gives the general aspects of the specification of supplementary services at the layer 3 radio 
interface. 

3GPP TS 24.08x and 24.09x-series specify the procedures used at the radio interface (reference point Um as defined in 
3GPP 24.002) for normal operation, registration, erasure, activation, deactivation, invocation and interrogation of 
supplementary services. Provision and withdrawal of supplementary services is an administrative matter between the 
mobile subscriber and the service provider and cause no signalling on the radio interface. 

3GPP TS 44.008 and 3GPP TS 24.080 specifies the formats and coding for the supplementary services. 

Definitions and descriptions of supplementary services are given in 3GPP TS 22.004 and 3GPP TS 22.08x and 
22.09x-series. 

Technical realization of supplementary services is described in 3GPP TS 23.01 1 and GSM 23.08x and 23.09x-series. 

The procedures for Call Control, Mobility Management and Radio Resource management at the layer 3 radio interface 
are defined in 3GPP TS 24.007 and 3GPP TS 44.008. 

1.1 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 21.905: "Abbreviations and acronyms". 

[2] 3GPP TS 22.004: "General on supplementary services". 

[3] 3GPP TS 22.081: "Line identification supplementary services - Stage 1". 

[4] 3GPP TS 22.082: "Call Forwarding (CF) supplementary services - Stage 1". 

[5] 3GPP TS 22.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 1". 

[6] 3GPP TS 22.084: "MultiParty (MPTY) supplementary services - Stage 1". 

[7] 3GPP TS 22.085: "Closed User Group (CUG) supplementary services - Stage 1". 

[8] 3GPP TS 22.086: "Advice of charge (AoC) supplementary services - Stage 1 " . 

[9] 3GPP TS 22.088: "Call Barring (CB) supplementary services - Stage 1". 

[10] 3GPP TS 22.090: "Unstructured Supplementary Services Data (USSD) - Stage 1". 

[II] 3GPP TS 22.091: "Explicit Call Transfer (ECT) supplementary service - Stage 1". 
[12] 3GPP TS 23. Oil: "Technical realization of supplementary services". 

[13] 3GPP TS 23.081: "Line identification supplementary services - Stage 2". 

[14] 3GPP TS 23.082: "Call Forwarding (CF) supplementary services - Stage 2". 

[15] 3GPP TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 2". 



£75/ 



3GPP TS 24.01 version 9.0.0 Release 9 7 ETSI TS 1 24 01 V9.0.0 (201 0-01 ) 

[16] 3GPP TS 23.084: "MultiParty (MPTY) supplementary services - Stage 2". 

[17] 3GPP TS 23.085: "Closed User Group (CUG) supplementary services - Stage 2". 

[18] 3GPP TS 23.086: "Advice of Charge (AoC) supplementary services - Stage 2". 

[19] 3GPP TS 23.088: "Call Barring (CB) supplementary services - Stage 2". 

[20] 3GPP TS 23.090: "Unstructured supplementary services operation - Stage 2". 

[21] 3GPP TS 23.091: "Explicit Call Transfer (ECT) supplementary service - Stage 2". 

[22] 3GPP TS 24.002: "GSM Public Land Mobile Network (PLMN) access reference configuration". 

[23] 3GPP TS 24.003: "Mobile Station - Base Stations system (MS - BSS) interface; Channel structures 
and access capabilities". 

[24] 3GPP TS 24.004: "Layer 1 ; General requirements". 

[25] 3GPP TS 44.005: "Data Link (DL) layer; General aspects". 

[26] 3GPP TS 44.006: "Mobile Station - Base Station System (MS - BSS) interface; Data Link (DL) 
layer specification". 

[27] 3GPP TS 24.007: "Mobile radio interface signalling layer 3; General aspects". 

[28] 3GPP TS 44.008: "Mobile radio interface layer 3 specification". 

[27] 3GPP TS 24.080: "Mobile radio interface layer 3 supplementary services specification; Formats 
and coding". 

[28] 3GPP TS 24.081: "Line identification supplementary services - Stage 3". 

[29] 3GPP TS 24.082: "Call Forwarding (CF) supplementary services - Stage 3". 

[30] 3GPP TS 24.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 3". 

[31] 3GPP TS 24.084: "MultiParty (MPTY) supplementary services - Stage 3". 

[32] 3GPP TS 24.085: "Closed User Group (CUG) supplementary services - Stage 3". 

[33] 3GPP TS 24.086: "Advice of Charge (AoC) supplementary services - Stage 3". 

[34] 3GPP TS 24.088: "Call Barring (CB) supplementary services - Stage 3". 

[35] 3GPP TS 24.090: "Unstructured supplementary services operation - Stage 3". 

[36] 3GPP TS 24.091: "Explicit Call Transfer (ECT) supplementary service - Stage 3". 

[37] 3GPP TS 45.001 : "Physical layer on the radio path; General description". 

[38] 3GPP TS 45.002: "Multiplexing and multiple access on the radio path". 

[39] 3GPP TS 45.003: "Channel coding". 

[40] 3GPP TS 45.004: "Modulation". 

[41] 3GPP TS 45.005: "Radio transmission and reception". 

[42] 3GPP TS 45.008: "Radio subsystem Hnk control". 

[43] 3GPP TS 45.010: "Radio subsystem synchronization". 

[44] GSM 05.90: "Digital cellular telecommunications system; GSM Electro Magnetic Compatibility 
(EMC) considerations". 

[45] 3GPP TS 29.002: "Mobile AppHcation Part (MAP) specification". 

[46] 3GPP TS 29.01 1: "Signalling interworking for supplementary services". 
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[47] CCITT Recommendation Q.774 (White Book): "Specifications of Signalling System No.7; 

Transaction capabilities procedures". 

1 .2 Abbreviations 

Abbreviations used in the present document are listed in 3GPP TS 21.905. 
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2 Generic procedures for the control of supplementary 

services 

2.1 Overview of the generic protocol and its scope 

One generic protocol is defined for the control of supplementary services at the radio interface. This protocol operates at 
layer 3 of the radio interface and assumes the use of layers 1 and 2 conform to 3GPP TS 45-series and 3GPP TS 44.004, 
3GPP TS 44.005 and 3GPP TS 44.006. The generic protocol uses the acknowledged information transfer service 
available at the layer 2 - layer 3 interface. 

The Functional protocol is based on the use of the Facility information element and the FACILITY message as well as 
other specific functional messages specified in 3GPP TS 24.080. 

Standardised services use a functional protocol. A transparent protocol is also provided. The functional protocol 
requires the knowledge of the related supplementary service by the mobile equipment supporting it. This facilitates 
mobile equipment operation without human intervention by defining semantics for the protocol elements which the 
mobile equipment can process on its own. 

2.2 Functional procedures for the control of supplementary 
services 

2.2.1 General 

This clause specifies the functional signalUng procedures for the control of supplementary services at the radio 
interface. 

The Functional protocol utilises functions and services provided by 3GPP TS 44.008 basic call control procedures and 
the functions of the data link layer as defined in 3GPP TS 44.00. 

In UMTS only, integrity protected signalling (see TS 24.008, subclause "Integrity Protection of Signalling Messages," 
and in general, see TS 33.102) is mandatory. In UMTS only, all protocols shall use integrity protected signalling. 
Integrity protection of all SS signalling messages is the responsibility of lower layers. It is the network which activates 
integrity protection. This is done using the security mode control procedure (TS 25.331). 

The defined procedures specify the basic methodology for the control (e.g. registration, erasure, invocation, etc.) of 
supplementary services. 

The first category, called the Separate Message Category utilises separate message types to indicate a desired function. 
The hold and retrieve families of messages are identified for this category. 

The second category called the Common Information Element Category utilises the Facility information element to 
transport the protocol defined in 3GPP TS 24.080. The use of the Facility information element is common to many 
services, and its contents indicates what type of procedure is being requested. This category can be signalled both in the 
mobile to network and the network to mobile directions. 

The control of supplementary services includes the following cases: 

a) the request of supplementary service procedures during the establishment of a call; 

b) the request of supplementary service procedures during the clearing of a call; 

c) the request of call related supplementary service procedures during the active state of a call; 

d) the request of supplementary service procedures independent from an active call; 

e) the request of multiple, different supplementary service procedures within a single message; 

f) the request of supplementary service procedures related to different calls. 
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The correlation of a call related supplementary service operation and the call which it modifies is provided by use of the 
transaction identifier (cases a, b, c, e and f). 

The correlation of supplementary service operations and their responses, is provided by the combination of the 
transaction identifier of the messages containing the Facility information element and the Invoke identifier present 
within the Facility information element itself (cases a, b, c, d, e and f). 

The identification of different supplementary service operations within one single message is provided by the Invoke 
identifier present within the Facility information element itself (case e). 

The identification of supplementary service related operations to different calls is provided by using different messages 
with the corresponding transaction identifier of the appropriate call (case f), i.e. different transaction identifier values 
are used to identify each call individually. 

2.2.2 Separate Messages Category 

The messages defined in this clause are specified as separate functional messages for the request, acknowledgement and 
rejection of specific procedures. These procedures can only be performed during the active phase of a call. The 
functions of these messages are not to be duplicated or overlapped by the ones of the Common Information Element 
Category. 

The following separate messages are defined: 

HOLD RETRIEVE 

HOLD ACKNOWLEDGE RETRIEVE ACKNOWLEDGE 

HOLD REJECT RETRIEVE REJECT. 

For detailed description of the Hold and Retrieve functions see 3GPP TS 24.083. 

2.2.3 Common Information Element Category 

The Common Information Element Category uses operations defined in 3GPP TS 24.080 for supplementary services 
signalling. Procedures are initiated by sending an operation including an invoke component. The invoke component 
may yield a Return Error, Return Result or Reject component (also included in an operation) depending on the outcome 
of the procedure. 

The operation state machines, and procedures for management of Invoke IDs specified in CCITT Recommendation 
Q.774 White Book are used. 

A REGISTER message, a FACILITY message or certain existing 3GPP TS 44.008 Call Control message is used to 
carry the Facility information element which includes these operations. These operations request, acknowledge or reject 
the desired supplementary service procedure. 

2.2.4 Call related supplementary service procedures 

2.2.4.1 Supplementary service procedures at call establishment or call clearing 

For call related supplementary service procedures initiated at call establishment or call clearing, the messages for call 
control specified in 3GPP TS 44.008 are utilised to transport Facility information elements. This enables, for example 
the originating mobile user to send a supplementary service invoke component within a SETUP message and to receive 
from the network a Return result. Return error, or Reject component type within the Facility information element in an 
ALERTING message, CONNECT message, or any other appropriate message. 
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When a supplementary service invoke component is included within a SETUP message, the originating mobile station 
shall encode the Facility information element identifier according to one of the three possible ways (see 3GPP TS 
44.008): 

a) simple recall alignment; 

b) advanced recall alignment; 

c) recall alignment not essential. 

Encoding of the Facility lEI within the SETUP message for different supplementary services is described in the 
subclause 2.2.4.1.1. 

The three different ways of encoding are required to support the network initiated mobile originating call establishment 
(see subclause 2.2.4.1.2 and 3GPP TS 44.008). 

2.2.4.1 .1 Encoding of the Facility IE! for different supplementary services 

The table 2.1 shows the encoding of the Facility lEI within the SETUP message for different supplementary services. 
Table 2.1 : Encoding of the Facility IE within the SETUP message 



Service 


FaciHtylE Encoding 


CUG 


simple recall alignment 


uus 


Advanced recall alignment 



2.2.4.1 .2 Supplementary service procedures at network initiated mobile originating call 

establishment 

The Facility and SS Version IE received in the set-up container of the CC_ESTABLISHMENT message shall be 
handled according to the following rules: 

The mobile station shall examine the lEI of the Facility IE. 

If the Facility lEI coding is "simple recall alignment", the mobile station shall copy the Facility IE and SS Version IE 
from the set-up container to the SETUP message without verifying or modifying the contents of these information 
elements. 

If the Facility lEI is encoded as "advanced recall alignment", the mobile station shall examine the SS Version IE. 

If the mobile station recognises the protocol defined by the SS Version IE, it shall attempt to decode the Facility IE. If 
the decoding is successful, and the operation is supported by the mobile station, the mobile station shall copy this 
Facility IE and SS Version IE to the SETUP message. The mobile station shall also store relevant supplementary 
service information contained within the Facility IE so that any reply to this Facility IE sent by the network will be 
properly understood and processed. 

If the mobile station does not recognise the SS Version IE, or the decoding of the Facility IE is unsuccessful, then the 
call is rejected as described in 3GPP TS 44.008. 

If the Facility IE is encoded as "recall alignment not essential", the mobile station shall examine the SS Version IE . 

If the mobile station recognises the protocol defined by the SS Version IE, it shall attempt to decode the Facility IE. 

If the decoding is successful, and the operation is supported by the mobile station, the mobile station shall copy this 
Facility IE and SS Version IE into the SETUP message. The mobile station shall also store relevant supplementary 
service information contained within the Facility IE so that any reply to this Facility IE sent by the network will be 
properly understood and processed. 

If the mobile station does not recognise the SS Version IE, or the decoding of the Facility IE is unsuccessful, then the 
SS Version IE and Facility IE are discarded, and NOT copied into the SETUP message. 
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NOTE: A mobile station may include a Facility IE without an associated SS Version IE. This would indicate that 
the SS operation is encoded using Phase 1 protocols. 

2.2.4.2 Supplementary service procedures during the call 

For call related supplementary service procedures during the active state of a call, the FACILITY message is used for 
the exchange of the Facility information elements. 

Note that the FACILITY message can also be used for this purpose in all states after the SETUP message has been sent. 

If the supplementary service procedure is related only to a single call, the FACILITY message will use the transaction 
identifier and protocol discriminator of this call. 

If the supplementary service procedure affects more then one call, the FACILITY message may use the transaction 
identifier and protocol discriminator of one of these calls. 

If a call related FACILITY message is sent using the transaction identifier of a call in progress, and this call is cleared 
due to call related causes, then the transaction identifier may not be cleared simultaneously in all cases. Depending upon 
the supplementary service invoked, one of the following will occur: 

the network or mobile user may retain both the connection and the transaction identifier association and may 
send a response within a Facility information element in a FACILITY message prior to the initiation of the 
normal call clearing procedures; or 

the network or mobile user may send a response with a Facility information element in the first clearing message 
(i.e. DISCONNECT, RELEASE or RELEASE COMPLETE message). 

2.2.4.3 Handling of protocol errors in call related SS procedures 

Messages containing a Facility information element shall be checked for protocol errors before the contents of the 
Facility IE is acted on. The checks shall be performed in the following order: 

1) The message carrying the Facility IE shall be checked for protocol errors as specified in 3GPP TS 44.008. If a 
protocol error is found then the procedures in 3GPP TS 44.008 apply. 

2) The contents of the Facility IE shall be checked for protocol errors as specified in subclause 2.2.8. If a protocol 
error is found then the procedures in subclause 2.2.8 apply. 

2.2.4.4 Handling of other errors in call related SS procedures 

If the tests specified in subclause 2.2.4.3 have been passed without the detection of a protocol error, the receiver will 
attempt to process the contents of the Facility Information Element. If errors occur during this processing (e.g. system 
failure, or information in the Facility IE is incompatible with the requested operation) then the procedures specified in 
the individual service specifications apply. 

Examples of the behaviour that could occur in this case are: 

the network or MS clears the call and rejects the supplementary services request by means of a clearing message 
which contains a Return Error component with the appropriate parameter in the Facility Information Element; 

the network and MS continue to process the call according to normal 3GPP TS 44.008 call control procedures. 
The supplementary services request is rejected by means of a FACILITY message or appropriate call control 
message containing a Return Error component with the appropriate parameter in the Facility Information 
Element; 

the network and MS continue to process the call according to the normal 3GPP TS 44.008 call control 
procedures. The supplementary services request is ignored. 
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2.2.5 Call independent supplementary service procedures 

2.2.5.1 introduction 

For supplementary service procedures independent of any call, the initiating side must establish a MM -connection 
between the network and the MS according to the rules given in 3GPP TS 24.007 and 3GPP TS 24.008. The call 
independent supplementary service procedures shall apply to both CS and PS domain for some specific services. On PS 
domain, a PS-signalling connection shall be established between the network and the MS instead of a MM-connection. 
Throughout this specification, the term MM-connection is used to denote a MM-connection for CS domain or PS- 
signalling connection for PS domain, as appropriate. The MS or the network starts the transaction by transferring a 
REGISTER message across the radio interface. This transaction is identified by the transaction identifier associated 
with the REGISTER message, and the Invoke identifier present in the component part of the Facility information 
element. Following the REGISTER message one or more FACILITY messages may be transmitted, all of them related 
by the use of the same transaction identifier. If the transaction is no longer used, it shall be released by sending a 
RELEASE COMPLETE message. This procedure is specified in detail in clause 3, and the text in clause 3 takes 
precedence over this introduction. 

To convey the supplementary service invocation, the Facility information element is used. The Facility information 
element present either in the REGISTER message or a subsequent message identifies the supplementary service 
involved and the type of component (i.e. Invoke, Return result. Return error or Reject component). 

When the REGISTER or FACILITY message contains a Facility information element and the requested service is 
available, a FACILITY message containing a Facility information element may be returned. One or more exchanges of 
FACILITY messages may subsequently occur. To terminate the service interaction and release the transaction identifier 
value, a RELEASE COMPLETE message is sent as specified for the specific supplementary service procedure. The 
RELEASE COMPLETE message may also contain the Facility information element. 

2.2.5.2 Handling of protocol errors in call independent SS procedures 

Messages containing a Facility information element shall be checked for protocol errors before the contents of the 
Facility IE is acted on. The checks shall be performed in the following order: 

1) The message carrying the Facility IE shall be checked for protocol errors as specified in subclause 3.7. If a 
protocol error is found then the procedures in subclause 3.7 apply. 

2) The contents of the Facility IE shall be checked for protocol errors as specified in subclause 2.2.8. If a protocol 
error is found then the procedures in subclause 2.2.8 apply. 

2.2.5.3 Handling of other errors in call independent SS procedures 

If the tests specified in subclause 2.2.5.2 have been passed without the detection of a protocol error, the receiver will 
attempt to process the contents of the Facility Information Element. If errors occur during this processing (e.g. system 
failure, or information in the Facility IE is incompatible with the requested operation) then the procedures specified in 
the individual service specifications apply. 

An example of the behaviour that could occur in this case is: 

the MS or network sends a Facility information element containing a return error component in a FACILITY or 
RELEASE COMPLETE message. If the FACILITY message is used then the MM Connection may continue to 
be used for further signalling. 

2.2.6 Multiple supplementary service invocations 
2.2.6.1 Call related supplementary service procedures 

Simultaneous requests for different supplementary service procedures (i.e. using more than one operation in the Facility 
information element) are permitted. Interactions between different operations shall be managed by processing the 
operations in the order in which they appear in the Facility information element. 
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2.2.6.2 Call independent supplementary service procedures 

Where permitted by the relevant stage 3 specification, muhiple operations may be sent on the same transaction. 

It is possible for several call independent SS transactions to be used simultaneously. Call independent SS transactions 
can also exist in parallel with other CM-Layer and MM transactions. The handling of multiple MM connections is 
defined in 3GPP TS 24.007 and 3GPP TS 44.008. 

For call independent operations a single Facility Information Element shall not contain more than one component. 

2.2.7 Recovery procedures 

2.2.7.1 Call related supplementary service recovery procedures 

There are no additional recovery procedures for call related supplementary service signalling on the radio path. The 
recovery procedures as specified for the basic service apply. 

2.2.7.2 Call independent supplementary service recovery procedures 

In case a transaction is not terminated according to the normal procedure as described in technical specifications 3GPP 
TS 24.08x and 24.09x-series, the network side has to ensure that the transaction is terminated e.g. by a supervision 
timer. 

2.2.8 Generic protocol error handling for the component part of 
supplementary services operations 

If (according to the rules specified in 3GPP TS 29.002) a supplementary service operation is to be rejected the operation 
will be denied, and provided the transaction is still in progress, an appropriate reject component will be returned in a 
Facility Information Element. 

The handling of the transaction depends on whether the operation is call related or call independent. 

2.2.8.1 Call related component errors 

If the call related transaction is still in progress then a reject component shall be sent. Any message which contains a 
Facility Information Element may be used. In general, the transaction (call) associated with the rejected operation shall 
not be automatically released by the entity that detects the error. The transaction (call) may be released in some 
exceptional cases where security related services are involved (e.g. Advice of Charge (Charging)). If this behaviour is 
required, then it will be specified in the relevant specification for the individual service. 

When a reject component for a call related operation is received by a MS or MSC then it may initiate release of the 
transaction (call) if this is a specified action for the service the SS operation relates to. 

Note that this behaviour is intended to allow security related services to release calls if one entity in the system does not 
support the service. The normal action should be to allow the call to continue. 

If the call related transaction has terminated before the operation has been rejected (e.g. the component containing the 
error was sent in a RELEASE COMPLETE message) then the contents of the component shall be ignored, and no reject 
component is sent. 

2.2.8.2 Call independent component errors 
2.2.8.2.1 Single component errors 

The reject component shall be sent in a RELEASE COMPLETE message. 

If the component containing the error was itself sent in a RELEASE COMPLETE message then the contents of the 
component shall be ignored, and no reject component is sent. 
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2.2.8.2.2 Multiple component errors 

If a single Facility IE contains more than one component then a RELEASE COMPLETE message with the cause 
"Facility rejected" and without any component shall be sent. 



3 Supplementary service support procedures 

3.1 General 

This clause describes the supplementary service support procedures at the radio interface. These procedures are 
provided by the supplementary service support entity defined in 3GPP TS 24.007. The supplementary service support 
procedures provide the means to transfer messages for the call independent supplementary service procedures. These 
procedures are regarded as the user of the supplementary service support. 

3.2 Supplementary service support establishment 

At the beginning of each call independent supplementary service procedure a supplementary service support must be 
established. 

3.2.1 Supplementary service support establishment at the originating side 

If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary 
service support entity shall first request the establishment of an MM-connection. This MM -connection is established 
according to 3GPP TS 44.008 and 04.07. If the network is the initiating side then MM-connection establishment may 
involve paging the MS. 

The supplementary service support entity shall send the REGISTER message as the first CM-message on the 
MM-connection. The REGISTER message is sent to the corresponding peer entity on the MM-connection and the 
supplementary service support shall be regarded as being established. 

3.2.2 Supplementary service support establishment at the terminating side 

At the terminating side a supplementary service support is regarded as being established when an MM-connection is 
established. According 3GPP TS 44.008 this can be ascertained by the receipt of the first message, with a new 
transaction identifier. For successful establishment of supplementary service support this message shall be a 
REGISTER message. 

If the terminating side wishes to reject the establishment of supplementary services support then it may be immediately 
initiate supplementary services support release (see subclause 3.4). 

3.3 Supplementary service support information transfer phase 

Upon the establishment of the supplementary service support both users may exchange FACILITY messages by use of 
the supplementary service support. 

3.4 Supplementary service support release 

At the end of each call independent supplementary service procedure the established supplementary service support is 
released. 

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its 
corresponding peer entity. 

Both supplementary service support entities release the MM-connection locally. 
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3.5 Recovery procedures 

The supplementary service support does not provide recovery procedures, i.e. the operations are transparent to the 
supplementary service support. 

3.6 Message flow (single operation example) 

This subclause contains examples of message flows for a single transaction consisting of a single operation. These 
examples may not show all possibilities. 

3.6.1 Mobile station initiated supplementary service transaction 

MS Network 

REGISTER 
> 

Facility (Invoke = Operation (Supplementary service code, Parameter(s))) 

RELEASE COMPLETE 
< 

Facility (Return result = Operation (Parameter(s))) 

RELEASE COMPLETE 

Facility (Return error (Error)) 

RELEASE COMPLETE 

Facility (Reject (Invoke_problem)) 

RELEASE COMPLETE (note) 
< ............... 

RELEASE COMPLETE (note) 



NOTE: To prevent transactions being kept open following exceptional cases, either side of the transaction may 
release it by sending a RELEASE COMPETE message without a Facility IE. 

Figure 3.1 : Mobile station initiated supplementary service transaction 
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3.6.2 Network initiated supplementary service transaction 

MS Network 

REGISTER 
< 

Facility (Invoke = Operation (Supplementary service code, Parameter(s))) 

RELEASE COMPLETE 
> 

Facility (Return result = Operation (Parameter(s))) 

RELEASE COMPLETE 

Facility (Return error (Error)) 

RELEASE COMPLETE 
> 

Facility (Reject (Invoke_problem)) 
RELEASE COMPLETE (note 1, note 3) 

RELEASE COMPLETE (note 3) 

NOTE 1 : If the network initiated operation does not require a result, reject or error to be returned then the MS shall 
release the transaction by sending a RELEASE COMPLETE message without a Facility Information 
Element. 

NOTE 2: For network initiated unstructured SS data alternative procedures for connection release apply; refer to 
3GPP TS 23.090 and 3GPP TS 24.090. 

NOTE 3: To prevent transactions being kept open following exceptional cases, either side of the transaction may 
release it by sending a RELEASE COMPETE message without a Facility IE. 

Figure 3.2: Network initiated supplementary service transaction 

3.7 Handling of unknown, unforeseen, and erroneous protocol 
data 

3.7.1 General 

These procedures only apply to messages where the protocol discriminator is set to indicate call independent SS 
operations according to the rules in 3GPP TS 24.007 and 3GPP TS 24.080. Messages that do not meet this criteria are 
treated according to other GSM technical specifications. 

This subclause specifies procedures for handling of unknown, unforeseen and erroneous protocol data by the receiving 
entity. The procedures are called "error handling procedures", but they also define a compatibility mechanism for future 
extension of the protocol. 

Most error handling procedures are mandatory in the MS, but optional in the network. Detailed error handling 
procedures may vary from PLMN to PLMN. 

In this subclause, the following terminology is used: 

An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved" 
in 3GPP TS 24.080 or 3GPP TS 44.008. However, it is not a syntactical error if a type 4 IE specifies a length 
indicator greater than that defined. The component part of the Facility information element is handled by a 
separate mechanism, and errors in the component part are not covered by this subclause. 
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The following procedures are listed in order of precedence. 

Handling of errors in the contents of the Facility IE is described in subclause 2.2.8, and is outside the scope of this 
subclause. 

3.7.2 Message too short 

When a message is received that is too short to contain a complete message type information element, that message 
shall be ignored. 

3.7.3 Unknown or unforeseen transaction identifier 

The MS shall ignore messages with the transaction identifier value set to "111". 

If the transaction identifier value is not "111" the following procedures shall apply to the MS: 

a) If a RELEASE COMPLETE message is received specifying a transaction identifier that is not recognised as 
relating to a call independent SS transaction that is in progress then the message shall be ignored. 

b) If a FACILITY message is received specifying a transaction identifier that is not recognised as relating to a call 
independent SS transaction that is in progress then a RELEASE COMPLETE message shall be sent with cause 
value #81 "invalid call reference value". 

c) If a REGISTER message is received specifying a transaction identifier that is not recognised as relating to a call 
independent SS transaction that is in progress and with a transaction identifier flag incorrectly set to "1", this 
message shall be ignored. 

The network may follow the same procedures. 

3.7.4 Unl<nown or unforeseen message type 

If the MS receives a message type not defined for the protocol discriminator or not implemented by the receiver, then a 
RELEASE COMPLETE message shall be sent with cause value #97 "message type non-existent or not implemented". 

If the MS receives a message type not consistent with the transaction state then a RELEASE COMPLETE message 
shall be sent with cause value #98 "message not compatible with control state". 

The network may follow the same procedures. 

3.7.5 Non-semantical mandatory Information Element Error 

When on receipt of a message: 

an "imperative message part" error; or 

a "missing mandatory IE" error; 
is diagnosed, or when a message containing: 

a syntactically incorrect mandatory IE; or 

an IE unknown in the message, but encoded as "comprehension required" (see 3GPP TS 44.008); or 

an out of sequence IE encoded as "comprehension required"; 
is received, the MS shall proceed as follows: 

a) If the message is not RELEASE COMPLETE it shall send a RELEASE COMPLETE message with cause "#96 - 
Invalid mandatory information". 

b) If the message is RELEASE COMPLETE, it shall be treated as a normal RELEASE COMPLETE message. 
The network may follow the same procedures. 
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3.7.6 Unknown and Unforeseen lEs in the non-imperative part 

3.7.6.1 lEIs unknown in the message 

The MS shall ignore all lEs unknown in the message which are not encoded as "comprehension required". 
The network shall take the same approach. 

3.7.6.2 Out of sequence lEs 

The MS shall ignore all out of sequence lEs in a message which are not encoded as "comprehension required". 
The network may take the same approach. 

3.7.6.3 Repeated lEs 

If an information element with format T, TV or TLV (see 3GPP TS 24.007) is repeated in a message in which repetition 
of the information element is not specified, only the contents of the information element appearing first shall be handled 
and all subsequent repetitions of the information element shall be ignored. When repetition of information elements is 
specified, only the contents of specified repeated information elements shall be handled. If the limit on repetition of 
information elements is exceeded, the contents of information elements appearing first up to the limit of repetitions 
shall be handled and all subsequent repetitions of the information element shall be ignored. 

The network may follow the same procedures. 

3.7.7 Non-imperative message part errors 

This category includes: 

syntactically incorrect optional lEs; 

conditional IE errors. 
Errors in the content of the Facility IE are handled according to subclause 2.2.8. 

3.7.7.1 Syntactically incorrect optional IBs (other than Facility) 

The MS shall treat all optional lEs that are syntactically incorrect in a message as not present in the message 
The network shall take the same approach. 

3.7.7.2 Conditional IE errors 

When the MS upon receipt of a message diagnoses a "missing conditional IE" error, or an "unexpected conditional IE 
error", or when it receives a message containing at least one syntactically incorrect conditional IE (other than Facility), 
it shall send a RELEASE COMPLETE message with cause #100 "conditional IE error". 

The network may follow the same procedure. 
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4 Password management 

The password management procedures consist of two independent procedures: 
password check; 
password registration. 

4.1 Password check 

4.1.1 Successful procedure 

When the password check procedure is invoked by a parent procedure (e.g. for service activation, service deactivation, 
password registration), the network sends to the MS an invoke component of the operation "get password" with 
"password" as the value of the mandatory Guidancelnfo information element. This invoke component is embedded in a 
FACILITY message, since the password check procedure is always invoked during an existing transaction. The MS will 
return to the network the required password in the return result component of the operation. This return result 
component is embedded in a FACILITY message, see figure 4. 1 . If the provided password is right the password check 
procedure returns to the parent procedure an indication of successful password check. 

MS Network 

REGISTER (note) 

Facility 

FACILITY 
< 

Facility (Invoke = GetPassword (Guidancelnfo = "password")) 

FACILITY 
> 

Facility (Return result = GetPassword (Password)) 
RELEASE COMPLETE (note) 

NOTE: This message is part of the initiating SS operation. 

Figure 4.1 : Password check: successful procedure 

4.1.2 Error cases 

If no result is returned by the MS for the "Get password" operation invoked by the network, the password check 
procedure is terminated. 

If the password value which is returned by the MS does not match the password value registered in the network, the 
network increments a counter and sends to the MS a Return Error component indicating "Negative Password Check". 
The counter is reset as soon as the right password is returned. 

If the served mobile subscriber enters a wrong call barring "password" three consecutive times, the subscription option 
"control of services" is set to "by the service provider" in the network: thus the network makes the use of password 
impossible for any subscriber operation. The password check procedure returns to the parent procedure an indication of 
Password Attempts Violation. The password can be made valid by the service provider only. 
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4.2 Password registration 



If the served mobile subscriber is given the possibiHty to control the service by the use of a password, the service 
provider has to register a password at provision time. Furthermore, the served mobile subscriber can change the call 
barring password at any time. 

The password registration procedure is as follows: 

When the mobile subscriber wants to register a new password the old password, the new password and the repeat of the 
new password shall be entered into the MS. Then the MS sends to the network an invoke component of the operation 
"register password". 

The common SS-code for call restriction services shall be used, but if the service code is not entered by the user the MS 
shall include the SS-code referring to all supplementary services. 

4.2.1 Successful procedure 

The successful procedure consists of three steps: 

the password registration procedure invokes first the password check procedure as it is described above; 

if the password check procedure has returned an indication of successful password check, the network sends 
secondly to the MS, in an invoke component of the operation "get password" with "new password?" as the value 
of the mandatory Guidancelnfo information element. This invoke component is embedded in a FACILITY 
message. The MS will return to the network the required new password in the return result component of the 
operation. This return result component is embedded in a FACILITY message; 

the network sends thirdly to the MS an invoke component of the operation "get password" with "new password 
again?" as the value of the mandatory Guidancelnfo information element. This invoke component is embedded 
in a FACILITY message. The MS will return again to the network the required new password in the return result 
component of the operation. This return result component is embedded in a FACILITY message. 

If the two values of the provided passwords are identical, the network confirms the registration of the new password by 
sending to the MS the return result component of the operation "register password", with the new password as a 
mandatory information element, see figure 4.2. 

4.2.2 Error cases 

If the subscription option "control of services" is set to "by the service provider" or if the WPA is greater than 3 an 
attempt to register a password will be denied by the network (see 3GPP TS 23.01 1). If the counter for wrong password 
attempts is smaller than four, the network will return to the MS an error component with the error value 
"SS_Subscription Violation". If the counter is larger than three, the error value "Password Attempts Violation" is 
returned. 

If the password check procedure returns an indication of negative password check, the network will send to the MS a 
return error component of the operation "register password" with the error value "negativePasswordCheck". 

If the new password is not repeated twice identically by the mobile subscriber, the network returns to the MS an error 
component of the "register password" operation with the error value "passwordRegistrationFailure". The diagnostic 
"newPasswordsMismatch" may be passed as an error parameter. The old password remains registered. 

If no result is returned by the MS for the "Get password" operation invoked by the network the "register password" 
procedure is terminated, and the old password remains registered. 

If the format of a new password which is returned by the MS is invalid (e.g. the value does not belong to 
the [0000-9999] range), the network sends to the MS an error component of the "register password" operation with the 
error value "passwordRegistrationFailure". The diagnostic "invalidFormat" may be passed as an error parameter. The 
old password remains registered. 
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MS Network 

REGISTER 
> 

Facility (Invoke = Register Password (SS-Code)) 

FACILITY 
< 

Facility (Invoke = GetPassword (Guidancelnfo = "password")) 

FACILITY 
> 

Facility (Return result = GetPassword (Password)) 

FACILITY 
< 

Facility (Invoke = GetPassword (Guidancelnfo = "new password")) 

FACILITY 
> 

Facility (Return result = GetPassword (Password)) 

FACILITY 
< 

Facility (Invoke = GetPassword (Guidancelnfo = "new password again")) 

FACILITY 
> 

Facility (Return result = GetPassword (Password)) 

RELEASE COMPLETE 
< 

Facility(Return result = Register Password (Password)) 

RELEASE COMPLETE 

Facility (Return error (Error)) 

RELEASE COMPLETE 
< ............ 

Facility (Reject (Invoke_problem)) 

NOTE: The figure illustrates successful outcome only. In case of input errors by the mobile subscriber, the 
information flow may be interrupted as defined in 3GPP TS 23. Oil. 

Figure 4.2: Password registration procedure 



4.3 Cross phase compatibility 



When password procedures are initiated by an MS which does not provide an SS version indicator and where errors 
occur in password procedures, the network shall not send the protocol error values "DataMissing", "CallBarred" or 
"NumberOfPW Attempts Violation" . 

When an MS that supports version 2 of the SS-protocol receives the guidance values "badPW-TryAgain" or 
"badPW-FormatTry Again" it shall release the transaction and notify the mobile user in the same way as if the error 
value "negativePasswordCheck" has been returned by the network in reply to the parent operation. 
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5 Supplementary service cross phase compatibility 

5.1 Cross phase, or cross protocol version, interworking 

Due to the phased approach to GSM standardisation it is possible for a service to be changed, or new services to be 
added, between different versions of the standard. Since GSM supports the features "terminal mobility" and "roaming" 
and is a system of open interfaces, it is possible for entities supporting different versions of the standards to have to 
interwork. This clause describes the supplementary service procedures which provide this interworking. 

This clause describes compatibility procedures for radio interface SS operations. In this clause the term "SS operation" 
refers to one of the operations sent in the Facility IE as defined in 3GPP TS 24.080 and 3GPP TS 29.002. An "MS 
initiated operation" is an SS operation where the MS sends the invoke component. A corresponding definition applies to 
network initiated operations. 

5.2 Objectives 

The objectives of these procedures are as follows: 

to allow flexibility of implementation, i.e. allow different combinations of services to be supported at different 
versions within a single entity; 

to allow SSs to evolve from version to version of the standards; 

to decouple SS protocol from other protocols; 

to guarantee the best quality of service in situations where different entities support different versions of that 
service. 

5.3 Supplementary service compatibility philosophy 

The purpose of the SS compatibility procedures is to ensure that when a service is invoked the highest common version 
of the service protocol is used in the entities supporting that service. The highest protocol version gives the best level of 
service to the subscriber. The commonality of versions between entities provides compatibility. 

The basic philosophy is that the MS shall provide the network with information about its capabilities in order that the 
network may adjust to the capabilities of the MS. This ensures that compatible information is sent to the MS. This 
process is not required in the other direction, i.e. the network does not provide the MS with capability information. The 
network is expected to be able to cope with unexpected information cleanly and due to network evolution will generally 
be more advanced than operating MSs. 

In this description the terms "phase" and "version" are used with respect to supplementary services. In this context 
"phase" means a particular collection of GSM standards or an implementation according to that phase of standards. In 
each phase of GSM standards "versions" of a service or protocol are described. Therefore it is sometimes applicable to 
refer to which version of a service is supported. 



£75/ 



3GPP TS 24.01 version 9.0.0 Release 9 24 ETSI TS 1 24 01 V9.0.0 (201 0-01 ) 



5.4 Compatibility mechanisms 



Two signalling indicators are used in the MS to network direction to provide information on the general capabilities of 
the MS and on specific SS protocol versions. A protocol extension mechanism is also used for protocol evolution. 

NOTE: These compatibility mechanisms are flexible, and could be applied in ways outside the scope of this 
standard. In general, MSs and networks should support complete implementations of supplementary 
services (e.g. mobile initiated USSD) including all elements that are not explicitly indicated as 
manufacturer or operator options. Complete support for a service also implies that the necessary 
compatibility indicators are set to appropriate values. If the MS or network does not implement all the 
elements necessary to support a service then the user may receive only a subset of the complete service. 
Such a MS or network is outside the scope of this standard and may: 

- provide a version of the service that is unpredictable or inconsistent; 
fail to meet important service requirements; 

- be incompatible with other entities. 

5.4.1 SS screening indicator 

The SS screening indicator is sent by the MS at the beginning of the radio connection to allow the network to assess the 
capabilities of the MS and hence determine, 

whether a particular network initiated SS operation may be invoked; or 

what version of a network initiated SS operation should be invoked. 

The SS screening indicator is only relevant to network initiated SS operation and is valid for the duration of a radio 
connection. The coding of the SS screening indicator is described in 3GPP TS 44.008 and 3GPP TS 24.080. 

5.4.2 SS version indicator 

The SS version indicator is sent by the MS and is associated with one or more related SS operations. It indicates to the 
network the correct version of radio interface protocol and procedures to use for those SS operations. For call related 
SSs the version indicator is valid for the invocation period of the SS operation to which it was attached (i.e. the validity 
of the invoke ID). For call independent SSs the indicator is valid for the duration of the call independent transaction. 
The SS version indicator takes precedence over the screening indicator during its period of validity. The coding of the 
SS version indicator is described in 3GPP TS 44.008 and 3GPP TS 24.080. 

5.4.3 Protocol extension mechanism 

A protocol extension mechanism is used in the common information element category supplementary service protocol 
to allow controlled evolution of the protocol. The purpose of this mechanism is to allow optional information to be 
introduced into operations without causing receiving entities, who do not recognise this information, to reject the entire 
operation. 

5.5 SS compatibility procedures 
5.5.1 Screening indicator procedures 
5.5.1.1 MS procedure 

If a MS supports Phase 2 3GPP TS 24.010 error handling and the Phase 2 3GPP TS 24.080 extension mechanism it 
shall send the screening indicator to the network during layer 3 connection establishment. The value of the indicator 
shall indicate Phase 2. The sending of the screening indicator does not depend upon the invocation of any 
supplementary service. 
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5.5.1 .2 Network procedure 

At layer 3 connection establishment with the MS, the network shall check for the SS screening indicator and note, for 
the duration of the connection, whether the indicator was sent, and if sent, the value of the indicator. 

On invocation of any network initiated SS operation (unless an SS version indicator has taken precedence over the 
screening indicator) the network shall check the screening indicator status. If the screening indicator was not sent, the 
network shall screen information sent to the MS, i.e. invoke the Phase 1 version of the operation or abort the invocation 
if only a Phase 2 version is available. If the screening indicator was received, indicating that Phase 2 error handling and 
extension mechanisms are supported at the MS, the network shall invoke the highest supported version of the operation 
toward the MS. 

According to this version of the standards the highest version is Phase 2. However when the next version of standards is 
available, new services may also be invoked. If the MS does not support the service the error handling or extension 
mechanism will handle unrecognised information cleanly. 

If in the future a new value is assigned to the screening indicator, new screening procedures may also be defined for 
networks of similar or higher capability. These procedures cannot be predicted and no definition is required in this 
version of the standards. 

If the value of the screening indicator is unrecognised the network shall attempt to handle network initiated SS 
operations as if the MS had indicated the highest values supported by the network. 

The indicator has been defined in such a way that it is ignored when received by a Phase 1 network therefore no Phase 1 
procedures are described. 

5.5.2 SS version indicator procedures 
5.5.2.1 MS procedure 

If an SS operation has been initiated at the MS, and the MS supports Phase 2 3GPP TS 24.010 error handling and the 
Phase 2 3GPP TS 24.080 extension mechanism and the operations used by the mobile initiated procedure are 
implemented according to the Phase 2 GSM standards, then: 

in the case of call independent activity, the MS shall send the SS version indicator at the beginning of the 
transaction indicating the version of the SS operation being invoked. No further indication shall be sent by the 
MS during the transaction. No operations shall be sent within the same transaction which are not compliant with 
the SS version indicated. 

in the case of call related activity, the MS shall send the SS version indicator in the 3GPP TS 44.008 message 
containing the invoke component of the related operation. The version of the service being invoked is indicated. 
This procedure applies on a per operation basis and shall be repeated for each call related operation. 

5.5.2.1 .1 MS procedure for version 3 or higher operations 

The relevant stage 3 specification for each service shall state if the operation requires the use of SS version 3 or higher 
for MS initiated operations. 

The SS version indicator is used within the network to define the MAP Application Context used for a specific 
operation (see 3GPP TS 29.002). An MS initiating an SS version 3 or higher operation must be able to decode all of the 
possible returned information from the MAP Version 3 Application Context of the operation invoked. 

If an SS version 3 or higher operation has been initiated at the MS, then: 

in the case of call independent activity, the MS shall send the SS version 3 or higher indicator at the beginning of 
the transaction indicating the version of the SS operation being invoked. No further indication shall be sent by 
the MS during the transaction. No operations shall be sent within the same transaction which are not compliant 
with the SS version indicated. 

in the case of call related activity, the MS shall send the SS version 3 or higher indicator in the 3GPP TS 44.008 
message containing the invoke component of the related operation. The version of the service being invoked is 
indicated. This procedure applies on a per operation basis and shall be repeated for each call related operation. 
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5.5.2.2 Network procedure 

5.5.2.2.1 Call independent SS activity 

When a new transaction is set up for call independent SS activity the network shall check for the SS version indicator 
and note, for the duration of the transaction, whether the indicator was present, and if present, the value of the indicator. 

The network shall use this indication to establish the correct MAP application context in the network for the processing 
of all operations made on that transaction. The network shall discard this information at the end of the transaction. If the 
indicator was not present the network shall operate according to Phase 1 . If the indicator was present and indicates 
Phase 2 the network shall operate according to the Phase 2 standards. If the value of the indicator is unrecognised the 
network shall attempt to handle the communication at its highest possible version. The detailed interworking for this 
situation is described in subclause 5.5.4. 

The screening indicator shall not be taken into account for processing transactions that start with MS initiated 
operations. 

Special procedures concerning SS version indicator values other than Phase 2 will be described in future standards if 
required. 

5.5.2.2.2 Call related SS activity 

When a call related common information element SS operation is received by the network, the network shall check the 
3GPP TS 44.008 carrier message for the SS version indicator. The network shall note whether the indicator was present, 
and if present, what value was provided. 

The network shall use this information to operate in a compatible way and set up compatible contexts in the fixed 
network. If the indicator was not present the network shall operate according to Phase 1 . If the indicator was present and 
indicates Phase 2 the network shall operate according to the Phase 2 standards. If the value of the indicator is 
unrecognised the network shall attempt to handle the communication at its highest possible version. 

The network shall discard the indicated information when the operation has been completed, i.e. when a result, error or 
reject is provided. If no response is expected to an operation the indicator is discarded immediately after the operation 
has been processed. 

The screening indicator shall not be taken into account for processing MS initiated operations. 

If the version indicator is received but no supplementary service information is supplied the network shall ignore the 
indicator. 

Special procedures concerning SS version indicator values other than Phase 2 will be described in future versions of the 
standards if required. 

5.5.3 Extension mechanism procedures 

The handling of the extension mechanism (ellipsis) is a detailed protocol matter and is described in the MAP version 2, 
3GPP TS 29.002. 

5.5.4 SS version indicator - MAP context interworking 
5.5.4.1 Call independent interworking 

The compatibility mechanisms described in these subclauses concern the radio interface. The fixed network protocol 
MAP also specifies compatibility mechanisms. The interworking between these mechanisms occurs at the MSCA'^LR. 

The MSC shall operate and set up contexts according to the version indicated by the MS wherever possible. If the MS 
signals a higher version than the MSC/VLR is capable of supporting, the MSC/VLR shall attempt to support service at 
the highest version which is supported. If this is not possible then the communication is rejected. 

Detailed interworking is described in 3GPP TS 29.01 1. 
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5.5.4.2 Call related interworking 

No interworking identified. 

5.6 Development of future protocol versions 

As a general rule all future versions of protocol should be designed such that they are a superset of the previous 
protocol. This provides backward compatibility. 

Optional information shall be introduced, where appropriate, in the extensible parts of operations. 

Non-compatible protocol changes, i.e. the introduction of mandatory protocol elements or new operations shall cause an 
increment in the protocol version. This shall be reflected in the use of the SS version indicator. Amendments to the 
Phase 2 services shall specify in the relevant stage 3 specification which value of the SS version indicator to use for MS 
initiated operations. 

The extension mechanism shall be introduced wherever possible in new operations or new constructed data types of the 
common information element SS protocol. 

Care should also be taken that functional service changes are made in a backwards compatible manner. 



6 Forward Check SS Indication 

The forward check SS indication procedure is used when supplementary services data in the HLR may have become 
corrupted. The procedure is initiated by the network to inform the user to verify his supplementary services data. The 
procedure consists of the network sending the ForwardCheckSSIndication operation on a call independent SS 
transaction. The procedure shall create a new network initiated transaction. 

The new transaction may be used on its own, or in parallel with other call independent SS transactions. The message 
flow is shown in figure 6.1. 

MS Network 

REGISTER 
< 

Facility (Invoke = ForwardCheckSSIndication) 

RELEASE COMPLETE 
> 

Figure 6.1 : ForwardCheckSSIndication sent on new transaction 
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Annex A (normative): 

Notation used for stage 3 description of supplementary 

services 

The structure of the signalling used for supplementary services on the Um Interface is defined using diagrams in 3GPP 
TS 24.010 and the 3GPP TS 24.08x and 24.09x-series of technical specifications. These SS stage 3 diagrams show 
example message flows between the MS and the network. 

Separate diagrams specify how supplementary services signalling shall be used to perform each defined supplementary 
service function. For signalling that uses the common information element approach, these diagrams are the normative 
definition of a number of important aspects of the supplementary services signalling: 

the diagrams normatively define the allowed responses to each supplementary service operation shown; 

the diagrams normatively define which 3GPP TS 44.008 or 3GPP TS 24.080 message is to be used to transport 
the supplementary services operations in the Facility IE; 

The diagrams normatively define which parameters are allowed and required in the invocation and response of 
each operation. 

A.1 General structure of the SS stage 3 diagrams 

In the SS stage 3 diagrams the messages that correspond to the normal case with successful outcome are shown using 
solid arrows. Messages for exceptional, or unsuccessful cases are shown using dashed arrows. In general, the diagrams 
show the initiating operation together with all possible outcomes. Obviously, in practice only one of the possible 
outcomes shown in the diagrams will occur when the operation is used. An example is given in figure A. 1 . 

MS Network 

Initiating Operation 
> 

Normal, Successful Outcome 
< 

Unsuccessful Outcome 1 
< .. ...... 

Unsuccessful Outcome 2 
< ................ .................. 

Figure A.I : Example of the general structure of the SS stage 3 diagrams 
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A.1 .1 Exceptional release procedures 



To prevent transactions being kept open following exceptional cases, either side of the transaction may release it by 
sending a RELEASE COMPETE message without a Facility IE. This procedure can be used to release any call 
independent SS procedure, at any time while supplementary service support is established. For clarity this is not shown 
on the specific diagrams in the 3GPP TS 24.08x and 24.09x series, though it is still available. 

MS Network 

RELEASE COMPLETE 



- or- 



RELEASE COMPLETE 



Figure A.2: Exceptional release procedures 



A.2 Messages used to transport operations 

The message used to transport the supplementary service operation is shown above the arrow. If a single message or a 
list of messages is specified then only these messages shall be used to transport the operation shown in the context 
shown. If the letters "e.g." are included before the message name or a list of messages then the messages shown are only 
suggested examples. If "e.g." is used then any message that carries the Facility information element which is consistent 
with the transaction state may be used for the SS operation. 



A.3 Contents of messages 



The contents of messages is specified below the arrow. The diagrams do not show the SS version indicator, or other 
parts of the message contents unless they are directly related to the service shown. The names of relevant information 
elements are shown, and the associated contents is shown in brackets. 

If the information element is the Facility IE then the contents information includes: 

the type of component that shall be used for the operation (e.g. invoke, return result, return error, reject); 

the name of the operation to be used (for the invoke and return result components only); 

the parameters that shall be included in the operation. For the function described by the diagram, only those 
parameters shown in the diagram are allowed. Unless stated otherwise all the parameters shown in the diagram 
shall be present when the operation is used for the function described by the diagram. 

The detailed encoding of the operations and parameters shown in the diagrams is defined in 3GPP TS 24.080 and 3GPP 
TS 29.002. Appropriate ASN.l structures from these specifications shall be used to align with the diagrams. 
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The examples in figure A. 2 illustrate the encoding. The first example shows a common information element operation 
where the operation name is shown. The second example shows a common information element operation where the 
operation name is not shown. Items in italics would be substituted with the appropriate identifiers. 

MESSAGE NAME 
> 

Facility (Component Type = OperationName (parameters)) 



MESSAGE NAME 

Facility (Component Type (parameters)) 

Figure A.2: Examples of the contents of messages 
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